WordPress 迁移与固定链接指南：从旧新浪 SAE 部署迁往现代主机

从 2011 年安装教程转为可回滚的迁移手册

2011 年原文依赖新浪 SAE 的邀请链接、特定控制台界面、“WordPress for SAE”一键安装和专用 rewrite 语法。当前维护版不再提供注册、推广或部署捷径；历史 slug 保持不变，但它不表示旧步骤仍然适用。

本文最后核对于 2026 年 9 月 1 日。目标是把一个仍在旧平台上的 WordPress 站点完整盘点、备份、迁移到经过验证的主机，并在不破坏固定链接的前提下切换和回滚。若你没有现存 SAE 应用，请从目标主机的实时兼容性、条款、价格和支持能力开始评估，不要依据本文注册任何平台。

1. 新浪 SAE 的当前证据边界

新浪云 SAE 产品页、登录页和支持中心在审计日仍可访问；官方 PHP 运行环境文档也仍记载 SAE 的 config.yaml、.htaccess 和 URL rewrite 行为。

但是，这些当前页面没有验证 2011 年邀请目标、当年的免费承诺、旧控制台按钮或“WordPress for SAE”一键安装项仍然存在。官方运行环境文档还明确警告：同一应用不要同时使用 .htaccess 与 config.yaml 的 handle 配置。因此，旧教程只应作为历史记录；现有用户应以自己控制台显示的运行时、服务清单、账单、导出能力和官方工单答复为准。

停止条件：无法登录现有账户、无法导出数据库或持久文件、无法确认域名控制权、平台只给出不完整备份，或目标主机尚未通过兼容性验证。不要先删除旧应用，也不要把 2011 年的 rewrite 片段直接粘贴进生产环境。

2. 冻结变更并建立完整清单

迁移前先确定负责人、维护窗口、可接受停写时间、恢复点目标（RPO）和恢复时间目标（RTO）。记录 DNS 托管方、TTL、证书、CDN／代理、邮件、定时任务、对象缓存、外部存储、分析脚本和所有非 WordPress 依赖。避免在盘点期间同时升级 WordPress、PHP、数据库、插件和主题。

在能安全运行 WP-CLI 的现有站点上，可采集不含凭据的版本清单：

set -euo pipefail

wp core version
wp core verify-checksums
wp option get home
wp option get siteurl
wp option get permalink_structure
wp plugin list --fields=name,status,version,update --format=json
wp theme list --fields=name,status,version,update --format=json
php -v
php -m | LC_ALL=C sort
mysql --version

不要把命令输出原样公开：插件、路径、主机名或错误信息可能暴露攻击面。若旧平台不允许 shell／WP-CLI，就从“工具 → 站点健康 → 信息”、控制台、数据库管理界面和文件导出逐项记录。

清单域	必须记录	验证问题
WordPress	核心版本、站点／首页 URL、固定链接、多站点状态	是否有硬编码 URL、MU 插件、drop-in 或自定义 cron
PHP	精确版本、SAPI、扩展、php.ini 限制、时区	主题和插件是否支持目标 PHP；上传／内存／执行时间是否足够
数据库	MySQL／MariaDB 产品与版本、引擎、字符集、排序规则、表前缀、大小	SQL mode、时区、最大包、权限和索引限制是否兼容
文件	核心、wp-content、uploads、主题、插件、配置、rewrite 文件	哪些路径持久化；是否有符号链接、外部对象存储或生成文件
外部系统	DNS、HTTPS、CDN、邮件、队列、缓存、webhook、计划任务	能否在 staging 替换或禁用；是否会向真实用户发送消息

3. 同时备份数据库和文件

WordPress 官方备份指南强调，完整恢复通常同时需要数据库与文件。“工具 → 导出”生成的 WXR 适合内容迁移，但官方导出说明列出的主要是文章、页面、评论、字段、分类、菜单和用户等内容；它不是插件、主题、配置和媒体二进制文件的完整灾难恢复备份。

在自主管理且允许 shell 的主机上，可使用如下有边界的示例。客户端配置必须为仅管理员可读，备份目录必须在 Web 根目录之外；在托管 PaaS 上则使用其官方数据库和持久存储导出功能。

set -euo pipefail
umask 077

BACKUP_DIR='/absolute/path/outside-web-root/wordpress-migration'
WORDPRESS_ROOT='/srv/wordpress'
MYSQL_CLIENT_CONFIG='/absolute/path/to/protected-client.cnf'
DATABASE_NAME='wordpress'

install -d -m 0700 "$BACKUP_DIR"
test -r "$MYSQL_CLIENT_CONFIG"
mysqldump --defaults-extra-file="$MYSQL_CLIENT_CONFIG" --single-transaction --routines --triggers "$DATABASE_NAME" > "$BACKUP_DIR/database.sql"
tar -C "$WORDPRESS_ROOT" -czf "$BACKUP_DIR/files.tar.gz" .
sha256sum "$BACKUP_DIR/database.sql" "$BACKUP_DIR/files.tar.gz" > "$BACKUP_DIR/SHA256SUMS"

--single-transaction 不是所有存储引擎和工作负载的通用一致性保证；按所用服务器版本阅读 MySQL Backup and Recovery。加密备份、限制读取、设置保留期，并在隔离环境真正恢复数据库和文件、核对校验和、文章数和抽样媒体。未做恢复演练的“备份成功”不构成迁移许可。

4. 用目标兼容性门禁代替“能安装”

WordPress 实时运行要求会更新；在执行日重新检查推荐的 PHP、MySQL／MariaDB 和 HTTPS 基线。不要只满足最低可启动版本：核心、主题、插件、PHP 扩展、数据库语义和运行方式必须作为一组验证。

门禁	通过标准	失败时动作
核心与 PHP	目标 PHP 在支持期内；staging 无致命错误、弃用洪水或校验和异常	先更换不兼容扩展／插件，或选择受支持的过渡运行时
插件与主题	来源、版本、维护状态、许可证和目标 WordPress／PHP 支持已核对	停用并替换无人维护或行为未知的组件；保留回滚包
数据库	精确产品／版本、字符集、排序规则、引擎和 SQL mode 经导入测试	修复转换方案并重新导入；不在唯一生产库上试错
文件与媒体	uploads、派生尺寸、权限、容量、inode 和持久化语义通过抽样	修复复制／对象存储适配并重新校验，不先切 DNS
平台能力	HTTPS、cron、邮件、缓存、备份、日志和恢复权限均已证明	缺一项就暂停，或书面接受明确的降级与补偿控制

重大版本升级最好拆分：先在尽量等价的运行时完成可逆迁移，再单独升级并测试。对已停更组件不要用“页面看起来正常”替代代码、安全和写入路径检查。

5. 在隔离 staging 中恢复与导入

按照 WordPress 迁移手册先保存旧站数据库和文件，再在不接收真实流量的 staging 恢复。Staging 应使用访问控制、禁用索引、禁用真实邮件／webhook／支付／分析上报，并对个人数据使用授权和最小化策略；它不能成为公开的生产副本。

建议顺序：创建空数据库和最小权限用户；恢复文件与数据库；检查 wp-config.php 中数据库连接、salt、缓存和环境常量；修复文件所有权而不是给全局写权限；验证管理员登录；再处理 URL。不要把备份、SQL、wp-config.php、日志或平台密钥放进 Git 或 Web 根目录。

若只能取得 WXR，可用 WordPress 导入工具恢复内容，但要单独迁移媒体、主题、插件和配置，并接受这不是完整同构恢复。若媒体由 SAE Storage、CDN 或插件映射到外部位置，必须导出原始对象、保存对象键与元数据，并逐批校验，而不是只复制 HTML 中的 URL。

6. 安全更新站点 URL 和序列化数据

确认目标 staging 已有完整备份后，分别核对 home 与 siteurl。WordPress 数据库中可能含 PHP 序列化值，不要用普通 SQL 文本替换。官方 `wp search-replace`能处理序列化数据，并提供 --dry-run。

set -euo pipefail

OLD_URL='http://legacy.example'
NEW_URL='https://www.example.com'

wp search-replace "$OLD_URL" "$NEW_URL" --all-tables-with-prefix --skip-columns=guid --dry-run

 # Review the dry-run report and backup checkpoint before this write.
wp search-replace "$OLD_URL" "$NEW_URL" --all-tables-with-prefix --skip-columns=guid
wp rewrite flush

先审查 dry-run 的表和替换数量，再执行写入。多站点需按官方命令语义评估 --network；不要盲目扩展到其他应用共用的表。检查 widgets、菜单、自定义字段、CSS、重定向、canonical、Open Graph、feed 和媒体附件；保留旧 URL 到新 URL 的一对一映射。不要无依据地改写 guid。

7. 固定链接是稳定 URL，不是“伪静态”营销词

WordPress 固定链接文档把 permalink 定义为应保持稳定的永久 URL。选择简洁结构，例如既有站点已经公开使用的 /%postname%/ 或历史 /html/%post_id%.html；迁移本身不是随意改结构的理由。

若必须改结构，先导出所有已发布文章、页面、分类、标签、分页、feed 和附件 URL，制作明确的逐条或模式化 301／308 映射，在 staging 检查冲突和重定向链。不要把所有旧 URL 都重定向到首页，也不要把真实 404 伪装成 200。WordPress 内部 rewrite 规则与 Web Server 路由必须一致。

8. Apache、Nginx 与 Caddy 的路由边界

以下是站点位于 Web 根目录时的最小路由示例，不是可直接复制到任何主机的完整虚拟主机。只选择实际使用的一个 Web Server，先备份配置并运行该服务器的语法测试。路径、PHP-FPM socket、权限和反向代理头必须按现场环境确认。

Apache 的根目录 .htaccess 示例依赖 mod_rewrite，并需要管理员允许相应 override；参考 Apache mod_rewrite：

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index[.]php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Nginx 应在正确的 server 块中用 `try_files`把不存在的路径交给 WordPress；PHP location 和 FastCGI 安全参数仍须单独正确配置：

location / {
    try_files $uri $uri/ /index.php?$args;
}

Caddy 的 `php_fastcgi`已包含面向 front controller 的 try-files 行为，通常要与 root 和 file_server 搭配：

example.com {
    root * /srv/wordpress
    encode zstd gzip
    php_fastcgi unix//run/php/php8.3-fpm.sock
    file_server
}

示例域名、根目录和 socket 都必须替换为已经验证的值。Apache 用 apachectl configtest、Nginx 用 nginx -t、Caddy 用 caddy validate --config /path/to/Caddyfile 验证，再优雅重载。SAE 现有应用若仍使用平台 config.yaml，只遵循其当前官方运行环境文档，且不要和 .htaccess 的 rewrite 混用。

9. HTTPS、DNS 与切换窗口

迁移前确认域名注册商和 DNS 账户可用，记录全部记录与 TTL；计划切换前至少一个 TTL 周期降低 TTL。先在目标主机完成 HTTPS 证书、SNI、完整证书链、HTTP 到 HTTPS 单跳重定向和 WordPress URL 测试。不要在目标尚未准备好时更改 nameserver 或删除旧证书。

用本地 hosts、临时受控域名或支持源站覆盖的测试方式访问新站，避免公开错误索引。切换时冻结写入或设计明确的数据增量同步；记录最后一次数据库快照与校验点，再改 DNS。保持旧环境只读且可恢复，直到 TTL、监控、日志、登录、发布、媒体和后台任务均稳定。CDN／代理缓存要按已审查范围清除，不能用全站清缓存掩盖源站错误。

10. 用读写路径测试，而不只是看首页

先把样例路径替换为 staging 中已知存在且不含私密信息的页面与媒体：

set -euo pipefail

BASE_URL='https://www.example.com'
SAMPLE_POST_PATH='/known-published-post/'
SAMPLE_MEDIA_PATH='/wp-content/uploads/2026/01/known-image.jpg'

for path in / "$SAMPLE_POST_PATH" "$SAMPLE_MEDIA_PATH" /wp-login.php /wp-json/; do
  curl --fail --silent --show-error --location --output /dev/null "${BASE_URL}${path}"
done

curl --silent --show-error --head "$BASE_URL/" |
  sed -n -e '/^HTTP[/]/p' -e '/^location:/Ip' -e '/^strict-transport-security:/Ip'

浏览器测试至少覆盖：首页、固定链接、分类／标签、搜索、分页、feed、REST API、登录／退出、创建和更新草稿、上传与生成缩略图。确认表单 nonce、角色权限、评论策略、缓存失效、cron、邮件沙箱、404、canonical 和旧 URL 重定向。比较迁移前后的文章／页面／评论／用户数量、关键表校验、媒体抽样和错误日志；性能测试要记录方法和数据量，不能只凭感觉。

11. 回滚不是“把 DNS 改回去”

触发器	立即动作	恢复证据
大量 5xx／rewrite 循环	停止新站写入，恢复上一版服务器配置	配置语法通过；固定 URL、静态文件和 404 恢复
登录、发布或媒体写入失败	保持维护模式，检查 PHP、权限、session、数据库和持久存储	管理员操作与新媒体在隔离测试中成功
数据缺失或编码损坏	停止双边写入，按最后一致快照恢复	行数、校验和、字符抽样和附件关系一致
切换后必须退回旧主机	记录新站变更边界，恢复旧站数据库／文件并切 DNS	不发生 split-brain；TTL 后监控和日志正常

回滚计划要写明决策人、阈值、备份 ID、恢复命令、DNS 记录、写入冻结和通信方式。若切换后已经产生评论、订单、用户或内容，不能简单覆盖；先停止写入并制定数据合并方案。保留失败环境的只读日志和时间线，但清理其中的凭据与个人数据。

12. 交付检查清单

• [ ] 旧平台的应用、数据库、持久文件、外部服务、账单与域名控制权已盘点。
• [ ] 数据库、完整文件和 WXR 内容导出均在受保护位置保存并校验。
• [ ] 至少一次隔离恢复成功，文章数、关键表与媒体抽样一致。
• [ ] 目标 WordPress、PHP、MySQL／MariaDB、插件、主题和扩展兼容性已证明。
• [ ] Staging 不索引、不发真实邮件／webhook／支付，不公开个人数据。
• [ ] URL 替换先 dry-run，序列化数据安全，guid 未被无依据改写。
• [ ] 只启用一种经过语法测试的 Web Server rewrite 路径。
• [ ] HTTPS、DNS、TTL、canonical、重定向与 CDN 缓存策略已演练。
• [ ] 读写、权限、媒体、cron、邮件沙箱、REST、feed、404 和日志均通过。
• [ ] 回滚触发器、写入冻结、备份 ID、负责人和数据合并边界已记录。
• [ ] 旧应用在验收与保留期结束前未删除；删除需另行审批和最终备份。
• [ ] 没有邀请、联盟、推广、旧下载或未经验证的平台承诺。

13. 当前官方资料

• 新浪云：云应用 SAE
• 新浪云：登录
• 新浪云：支持中心
• 新浪云：SAE PHP 运行环境
• WordPress：运行要求
• WordPress：备份
• WordPress：工具 → 导出
• WordPress：迁移
• WordPress：固定链接
• WP-CLI：search-replace
• WP-CLI：rewrite flush
• MySQL：Backup and Recovery
• Apache HTTP Server：mod_rewrite
• Nginx：try_files
• Caddy：php_fastcgi

14. 2011 年原文安全存档

以下保留 source_export 的完整可见正文，仅规范化行末空白，并对 13 个历史目标做窄范围替换：1 个新浪 SAE 邀请／引荐目标、11 个已失效旧站图片目标和 1 个已失效演示站目标。链接的可见文字及其他历史正文均保留；原始导出和 Git 历史仍保存未修改值。

警告：存档中的免费承诺、注册／安装步骤、控制台名称、密码提示、rewrite 配置和演示地址都是 2011 年历史内容，不是当前事实或操作建议。所有链接都位于外层代码围栏内，不应用作注册、下载、配置或部署入口。

在新浪SAE上安装wordpress并实现伪静态

核心提示：新浪SAE是Sina App Engine的简称，它是新浪免费提供的应用开发和运行平台，我们已经在前面介绍过。今天向大家介绍，如何在新浪SAE上建立自己的wordpress博客，并实现伪静态。

新浪SAE是Sina App Engine的简称，它是新浪免费提供的应用开发和运行平台，我们已经在前面介绍过。今天向大家介绍，如何在新浪SAE上建立自己的wordpress博客，并实现伪静态。

**1、注册帐号：**要使用新浪SAE搭建自己的博客，当然首先需要注册一个新浪SAE的帐号。注册地址：[http://sae.sina.com.cn/]([historical invitation/referral target redacted] )，现在已经可以和自己的新浪微薄进行绑定注册了。

![]([historical dead image target redacted])

**2、创建应用：**注册登录后，点击“我的应用”，能够显示出已经创建的应用列表。点击下面的创建新应用，进入应用设置。

![]([historical dead image target redacted])

**3、创建二级域名：**这里设置的就是我们所创建的应用的访问地址，设置好后直接点击创建应用，这个一个应用就创建完成了。

![]([historical dead image target redacted])

**4、安装wordpress博客程序：**创建应用后直接点击“推荐应用”，选择Wordpress for sae后面的安装，进入选择应用界面，这里为了安全，需要你输入注册时填写的安全验证密码。

![]([historical dead image target redacted])

这里，在第一项里选择我们刚刚建立的应用名称，第二项选择“安装为新版本”，第三项随便填入一个1-9的整数，然后点下面的“安装到以上位置”。

![]([historical dead image target redacted])

到这里系统会自动加载选择的应用程序，加载完成后会显示如下界面，点击“点击此处进入初始化页面点此管理该应用”进入博客的设置。

![]([historical dead image target redacted])

**5、设置wordpress。**也就是咱们最常见的设置，依次在下面输入你的站点标题、用户名、密码，点击确认，到这里，你的博客就已经建好了。访问地址就是你创建的应用地址。

![]([historical dead image target redacted])

**6、实现wordpress的伪静态：**伪静态的好处大家都清楚，但是常用的伪静态方法对SAE来说并不适用，SAE有自己的伪静态设置方法。首先从“应用列表”进入我们刚刚建立的应用。点击“应用管理”中的“代码管理”。

![]([historical dead image target redacted])

选择“操作”中的“编辑代码”

![]([historical dead image target redacted])

进入新的页面后，我们会看到，左上角有一个“Config Path”，SAE就是通过设置它来实现伪静态的。点击它，在右侧会显示它的编辑页面，在里面加入如下代码。

> handle:

> – rewrite: if(!is_dir() && !is_file()) goto “index.php?%{QUERY_STRING}”

如下图：

![]([historical dead image target redacted])

点击SAVE保存。

最后将wordpress里的固定链接格式设置成如下格式“/html/%post_id%.html”，这个可以根据个人喜好进行调整。

![]([historical dead image target redacted])

至此，wordpress的伪静态就设置完成了。

最后给大家一个演示，属于本站的一个备份，[http://earnfs.sinaapp.com/]([historical dead demo target redacted]) 。